Historically, controlling access to communication network resources has been accomplished by physical security techniques. In particular, a user would require physical access to the network, such as by being physically in a building, in order to obtain access to the network. A general assumption in this scenario is that access to the building entitled the user access to the network communication resources.
With the growth and now prevalence of wireless network access, the general assumption of physical access has been undone since it is impractical to limit radio waves to physical building boundaries. As a result, various software authentication techniques and protocols have been developed which require users or network devices to identify themselves to the network prior to being granted access to the network.
Simultaneously, requirements and conditions for granting network access have also become more complex. In some instances, network access may be location or time dependant. In other instances, network access may depend on a state of the device joining the network. The state may include factors such as a software version of the device, timely anti-virus checks, or firewall configuration. The state is frequently simply referred to as the health or posture of the device.
As a result of these and other requirements, network access control (NAC) has become a complex multi-faceted problem involving a multiplicity of cooperating components operating within a well-defined network access control framework. The cooperating components potentially include client software to assist in identification of the user and gathering of client device state, network access devices (NADs) which assist in the enforcement of access control decisions, and a policy decision point (PDP). The PDP is where a network operator specifies access control policies and where an access control decision is made. In addition, NAC frameworks generally also include various servers to assist the PDP such as audit servers to audit devices that do not have the necessary client software, or specialized health or posture validation servers (PVSs).
Several such frameworks have been proposed and are in early stages of deployment. Three such frameworks in particular are being actively adopted in the industry. The three frameworks are Cisco's Network Access Control (CNAC), Microsoft's Network Access Protection (NAP), and the Trusted Computing Group's Trusted Network Connect (TNC).
Each of these frameworks has its strengths and weaknesses such as varying degrees of client support (e.g., Windows XP® versus Linux® versus Vista®), access support (e.g., VPN versus 802.1x versus EAPoUDP), and enforcement support (e.g., VLANs versus downloadable ACLs versus filters). As a result, network operators are likely to deploy more than one framework in each of their respective networks. While similar, these frameworks do have significant differences that are problematic in a multi-framework deployment scenario.
Current state-of-the-art strategies in this nascent area dictate two deployment scenarios that can be adopted by an organization that require multiple NAC frameworks to meet their disparate assessment and operating requirements. In one scenario, the network access can be segmented in such a way that some assessments are done by one framework and others are done by a second framework. In another scenario, the PDP of one framework handles all assessment requests, but forwards or proxies assessments that it cannot handle to a PDP of another framework. One problem with either of these approaches is that the administrator has to manage policies on several PDPs, each one different from the other. Another problem is the complex, and perhaps subtle, interactions between the frameworks leading to inconsistent, or worse, incorrect results. Even in a seemingly unified deployment where assessments that cannot be handled by one PDP are forwarded to a PDP belonging to another framework, policy configurations can be conflicting, thus leading to incorrect enforcement of the NADs.
Therefore, what is needed is a solution that unifies multiple frameworks and coordinates their actions so that a correct end result is achieved. Such a unifying solution should meet the following requirements:                The solution should present a unified configuration interface so an administrator can configure all policies without regard to a specific framework;        The solution should seamlessly handle different types of clients, access types, enforcement mechanisms and underlying protocols, and application programming interfaces; and        The solution should be extensible so that it can embrace and function properly with new frameworks as the frameworks are developed and deployed.        
Problems with multi-framework deployments can also manifest themselves in single-framework deployments when the single framework is enhanced with new capabilities. Just as with multiple frameworks, new features and capabilities need to be integrated with existing ones and they should all be controlled together in a unified and coordinated way. It would therefore be advantageous to provide solutions to these and other related problems.